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Encrypting the Protocol for Carrying Authentication for 
Network Access (PANA) Attribute-Value Pairs 


Abstract 
This document specifies a mechanism for delivering the Protocol for 
Carrying Authentication for Network Access (PANA) Attribute-Value 
Pairs (AVPs) in encrypted form. 

Status of This Memo 


This is an Internet Standards Track document. 


This document is a product of the Internet Engineering Task Force 


(IETF). It represents the consensus of the IETF community. It has 
received public review and has been approved for publication by the 
Internet Engineering Steering Group (IESG). Further information on 


Internet Standards is available in Section 2 of RFC 5741. 


Information about the current status of this document, any errata, 
and how to provide feedback on it may be obtained at 
http://www.rfc-editor.org/info/rfc6786. 
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1. Introduction 


PANA [RFC5191] is a UDP-based protocol to perform an Extensible 
Authentication Protocol (EAP) authentication between a PANA Client 
(PaC) and a PANA Authentication Agent (PAA). 


Various types of payload are exchanged as part of the network access 
authentication and authorization. These payloads are carried in PANA 
Attribute-Value Pairs (AVPs). AVPs can be integrity protected using 
the AUTH AVP when EAP authentication generates cryptographic keying 
material. AVPs are transmitted in the clear (i.e., not encrypted). 


Certain payload types need to be delivered privately (e.g., network 
keys, private identifiers, etc.). This document defines a mechanism 
for applying encryption to selected AVPs. 


1.1. Specification of Requirements 


In this document, several words are used to signify the requirements 
of the specification. These words are often capitalized. The key 
words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", 
"SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document 
are to be interpreted as described in [RFC2119]. 
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Details 


This document extends the AVP set defined in Section 8 of [RFC5191] 
by defining two new AVPs: the Encryption-Algorithm AVP (see Section 
4) and the Encryption-Encap AVP (see Section 5). Two new encryption 
keys, PANA_PAC_ENCR_KEY and PANA_ PAA ENCR_KEY, are defined to encrypt 
AVPs from the PaC to the PAA and AVPs from the PAA to the PaC, 
respectively (see Section 3). 


When encryption is needed, the required algorithm is negotiated as 
follows: the PAA SHALL send the initial PANA-Auth-Request carrying 
one or more Encryption-Algorithm AVPs supported by it. The PaC SHALL 
select one of the algorithms from this AVP, and it SHALL respond with 
the initial PANA-Auth-Answer carrying one Encryption-Algorithm AVP 
for the selected algorithm. Once PANA_PAC_ENCR_KEY and 

PANA_PAA ENCR_KEY have been generated, a PANA message MAY contain an 
Encryption-Encap AVP. 


Encryption Keys 


PANA_PAC_ENCR_KEY is used for encrypting the AVP payload of the 
Encryption-Encap AVP sent in a PANA message from the PaC to the PAA. 


PANA_PAC_ENCR_KEY SHALL be computed according to the following 
formula: 


PANA_PAC_ENCR_KEY = prf+(MSK, "IETF PANA PaC Encr" | I_PAR | 
I_PAN | PaC_nonce | PAA_nonce | Key_ID) 


PANA_PAA_ENCR_KEY is used for encrypting the AVP payload of the 
Encryption-Encap AVP sent in a PANA message from the PAA to the Pac. 
PANA_PAA_ENCR_KEY SHALL be computed according to the following 
formula: 


PANA_PAA_ENCR_KEY = prf+ (MSK, "IETF PANA PAA Encr" | I_PAR | 
I_PAN | PaC_nonce PAA_nonce | Key_ID) 


In both cases: 


- The prf+ function is defined in the Internet Key Exchange 
Protocol version 2 (IKEv2) [RFC5996]. 


- The pseudo-random function (PRF) to be used for the prf+ 
function SHALL be negotiated using the PRF-Algorithm AVP in the 
initial PANA-Auth-Request and PANA-Auth-Answer exchange with 
the ’S’ (Start) bit set as described in Section 4.1 of 
[RFC5191]. 
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MSK is the master session key (MSK) generated by the EAP method 
[RFC3748]. PANA_PAC_ENCR_KEY and PANA_PAA ENCR_KEY MUST be 
recalculated whenever a new MSK is generated by the EAP method. 


"IETF PANA PaC Encr" and "IETF PANA PAA Encr"™ are the ASCII 
code representations of the respective non-NULL terminated 
strings (excluding the double quotes around them). 


I_PAR and I_PAN are the initial PANA-Auth-Request and 
PANA-Auth-Answer messages (the PANA header and the following 
PANA AVPs) with the ’S’ (Start) bit set, respectively. 


PaC_nonce and PAA_nonce are values of the Nonce AVP carried in 
the first non-initial PANA-Auth-Answer and PANA-Auth-Request 
messages in the authentication and authorization phase or the 
first PANA-Auth-Answer and PANA-Auth-Request messages in the 
re-authentication phase, respectively. 


Key_ID is the value of the Key-Id AVP. 


The length of PANA_PAC_ENCR_KEY and PANA_PAA ENCR_KEY depends on the 
encryption algorithm in use. 


4. Encryption-Algorithm AVP 


The Encryption-Algorithm AVP (AVP code 13) is used for conveying the 
encryption algorithm to be used with the Encryption-Encap AVP. The 
AVP value data is of type Unsigned32. 


Only one encryption algorithm identifier AES128_CTR (code 1) is 
identified by this document. Encryption algorithm identifier values 
other than 1 are reserved for future use. Future specifications are 
allowed to extend this list. 


AES128_CTR: 1 


In the absence of an application profile specifying otherwise, all 
implementations SHALL support AES128_CTR. 
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4.1. AES128_CTR Encryption Algorithm 


The AES128_CTR encryption algorithm uses the AES-CTR (Counter) mode 
of operation as specified in [NIST_SP800_38A] using the AES-128 block 
cipher. The formatting function and counter generation function, as 
specified in Appendix A of [NIST_SP800_38C], are used with the 
following parameters: 


n= 12, 
q= 3 


The 12-octet nonce consists of a 4-octet Key-Id, a 4-octet Session 
ID, and a 4-octet Sequence Number in that order where each 4-octet 
value is encoded in network byte order. The Session ID and Sequence 
Number values SHALL be the same as those in the PANA message carrying 
the key Encryption-Encap AVP. The Key-Id value SHALL be the same as 
the one used for deriving PANA_PAC_ENCR_KEY and PANA_PAA ENCR_KEY. 
The output blocks of the encryption processing are encoded as 
OctetString data in the Value field of a Encryption-Encap AVP. 


Note that the first counter block used for encryption is Ctr_1, where 
"1" denotes "subscript 1" as described in Appendix A.3 of 
[NIST_SP800_38C]. For example, given the following: 


Key-Id = 0x55667788, 
Session ID = Oxaabbccdd, 
Sequence Number = 0x11223344 
The first counter block used for encryption will be: 


0x0255667788aabbccdd11223344000001 


where the initial 0x02 represents the Flags field of the counter 
block. 


The nonce meets the requirement of uniqueness-—per-key usage provided 
that the sequence number does not wrap. Therefore, for the purpose 
of generating new keys: 


- If Encryption-Encap AVPs are being sent from the PaC to the PAA 
and the sequence number is about to wrap, the PaC SHALL 
initiate PANA re-authentication as described in Section 4.3 of 
[RFC5191]. 


- If Encryption-Encap AVPs are being sent from the PAA to the Pac 
and the sequence number is about to wrap, the PAA SHALL 
initiate PANA re-authentication as described in Section 4.3 of 
[RFC5191]. 
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Re-authentication ensures the generation of a new MSK [RFC3748] and 
thus a new PANA_PAC_ENCR_KEY and PANA_PAA ENCR_KEY. 

5. Encryption-Encap AVP 
The Encryption-Encap AVP (AVP code 12) is used to encrypt one or more 
PANA AVPs. The format of the Encryption-Encap AVP depends on the 


negotiated encryption algorithm. 


When the negotiated encryption algorithm identifier is AES128_CTR 
(code 1), AVP data payload is occupied by the encrypted AVPs. 


There SHALL be only one Encryption-Encap AVP in a PANA message. All 
AVPs that require encryption SHALL be encapsulated within the 
Encryption-Encap AVP. 


The Encryption-Encap AVP uses either PANA_PAC_ENCR_KEY or 
PANA_PAA ENCR_KEY, and the encryption algorithm negotiated by the 
Encryption-Algorithm AVP. The Encryption-Encap AVP SHALL only be 
used if the EAP method generates cryptographic keys (specifically, 
the MSK [RFC3748]). 


The Encryption-Encap AVP MAY be used in a PANA message from the Pac 
to the PAA when the encryption algorithm has been successfully 
negotiated and once PANA_PAC_ENCR_KEY has been generated. 


The Encryption-Encap AVP MAY be used in a PANA message from the PAA 
to the PaC when the encryption algorithm has been successfully 
negotiated and once PANA_PAA_ENCR_KEY has been generated. 


The Encryption-Encap AVP MAY be used in the very first PANA message 
carrying the Result-Code AVP set to PANA Success value and any 
subsequent message within the same PANA session. 


6. Encryption Policy 


The specification of any AVP SHOULD state that the AVP either shall 
or shall not be encrypted using the Encryption-Encap AVP. The 
specification of an AVP MAY state that the AVP may (or may not) be 
encrypted using the Encryption-Encap AVP. The specification SHOULD 
use a table in the format specified in Section 6.1. If the 
specification of an AVP is silent about whether the AVP shall or 
shall not be encrypted using the Encryption-Encap AVP, this implies 
that the AVP MAY be encrypted using the Encryption-Encap AVP. 
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Encryption Policy Specification 


This section defines a table format for the specification of whether 
an AVP shall or shall not be encrypted using the Encryption-Encap 
AVP. 


The table uses the following symbols: 


Y: 


The AVP SHALL be encrypted using the Encryption-Encap AVP. If the 
AVP is encountered not encrypted using the Encryption-Encap AVP, 
it SHALL be considered invalid and the message containing the AVP 
SHALL be discarded. 


The AVP SHALL NOT be encrypted using the Encryption-Encap AVP. If 
the AVP is encountered encrypted using the Encryption-Encap AVP, 
it SHALL be considered invalid and the message containing the AVP 
SHALL be discarded. 


The AVP MAY be encrypted using the Encryption-Encap AVP. If the 
AVP is encountered either encrypted or not encrypted using the 
Encryption-Encap AVP, it SHALL be considered valid. 


The legitimate occurrence of unencrypted AVPs and AVPs after 
decryption and unencapsulation SHALL be subject to the AVP Occurrence 
Table (Figure 4 in [RFC5191]). 


The following table shows the encryption requirements for the 
existing AVPs defined in [RFC5191]: 


Attribute Name | 
——— — — — + 
AUTH | 
EAP-Payload | 
Integrity-Algorithm | 
Key-Id 
Nonce | 
PRF-Algorithm | 
Result-Code | 
Session-Lifetime | 
Termination-Cause | 
+ 
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The following table shows the encryption requirements for the AVPs 
defined in [RFC6345]: 


Attribute Name |Enc | 
SSSSSassSssSss SSS 5S= tass 
PaC-Information | N | 
Relayed-Message | N | 
Sa ra a ate tio a gt +--—+ 


The following table shows the encryption requirements for the AVPs 
defined in this document: 


Attribute Name |Enc | 
---------------------- +--+ 
Encryption-Algorithm | N | 
Encryption-Encap | N | 
---------------------- 4+---+ 


The following table is an example showing the encryption requirements 
for a newly defined AVP, Example-AVP: 


Attribute Name 


The guidance for specifying the encryption requirements for a newly 
defined AVP is as follows: 


Y: If the payload needs privacy against eavesdroppers (e.g., carrying 
a secret key). 


N: If the payload may need to be observed by on-path network elements 
(i.e., subject to deep packet inspection). 


X: If neither concern applies. 

7. Security Considerations 
PANA_PAC_ENCR_KEY and PANA_PAA ENCR_KEY are secret keys shared 
between the PaC and the PAA. They SHALL NOT be used for purposes 
other than those specified in this document. Compromise of these 


keys would lead to compromise of the secret information protected by 
these keys. 
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1. AES-CTR Security Considerations 


The use of AES-CTR encryption has its own security considerations, 
which are detailed in the Security Considerations section of 
[RFC3686]. Specifically: 


- The nonce specified in Section 4.1 meets the requirement of 
uniqueness-—per-key usage. 


- Section 4.1 of [RFC5191] states that if the EAP method 
generates cryptographic keys, an AUTH AVP will always be 
present in every PANA message after key generation. Therefore, 
an Encryption-Encap AVP will always be sent in conjunction with 
an AUTH AVP. This meets the requirement of a companion 
authentication function. 


IANA Considerations 
As described in Sections 4 and 5, and following the IANA allocation 
policy on PANA messages [RFC5872], two PANA AVP codes and one set of 
AVP values have been registered. An additional encryption policy for 
AVP codes has also been registered. 
1. PANA AVP Codes 
The following AVP codes have been registered in the "AVP Codes" sub- 
registry of the "Protocol for Carrying Authentication for Network 
Access (PANA) Parameters" registry: 


o A standard AVP code of 12 for the Encryption-Encap AVP. 


o A standard AVP code of 13 for the Encryption-Algorithm AVP. 


-2. PANA Encryption-Algorithm AVP Values 


The following AVP values representing the encryption algorithm 
identifier for the Encryption-Algorithm AVP code have been assigned 
in the "Encryption-Algorithm (AVP Code 13) AVP Values" sub-registry 
under the "Protocol for Carrying Authentication for Network Access 
(PANA) Parameters" registry": 


o An AVP value of 1 for AES128_CTR. 
o All other AVP values (0, 2-4294967295) are unassigned. 


The registration procedures are IETF Review or IESG Approval in 
accordance with [RFC5872]. 
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8.3. PANA AVP Codes Encryption Policy 


The additional encryption policy defined in Section 6.1 has been 
added as a column labeled "Enc" in the "AVP Codes" sub-registry and 
has been applied to all existing AVP codes and those defined in this 
specification. 
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